FHS IPv6 Access lists are generic access/prefix lists which can be applied on IPv6 source address or the prefixes advertised in RA or DHCPv6 messages. If you filter on the basis of a particular IPv6 source address, you must configure the access list entry with complete source address with prefix-length value of 128. If you allow a group of source addresses within a prefix range, you must configure the IPv6 ACL entry with an appropriate prefix length and attach this IPv6 ACL to the appropriate match parameters in RA Guard or DHCPv6 Guard policies.
If you filter a particular prefix, you must configure an IPv6 access list entry with appropriate prefix and prefix-lengths. To filter based on prefix, prefix-lengths should be less than 128. Following is an example of IPv6 access list entry:
ipv6 fhs ipv6-access-list match_src_allow fe80:0:0:0:0:ff:fe00:113/128 mode allow
Note
If no IPv6 ACL is attached to an RA Guard or DHCPv6 Guard policy as a source ACL, then IPv6 source address in the incoming RA packets or packets from DHCP server will not be validated, and such packets will not be dropped due to source address validations.
If no IPv6 ACL is attached to an RA Guard or DHCPv6 Guard policy as a prefix ACL, then prefix information in incoming RA packets or packets from DHCP server will not be validated and these packets will not be dropped due to prefix validations.
The FHS access or prefix lists are different from IPv6 prefix lists. For FHS, the switch maintains a separate list (cannot reuse IPv6 prefix lists) as IPv6 prefix lists do not have any action associated with them, whereas FHS has an action associated with each ACL entry.
When an IPv6 ACL is attached to an RA Guard or DHCPv6 Guard policy and the address or prefix in the incoming RA Guard or DHCPv6 server packets received on port to which this RA Guard or DHCPv6 Guard policy is attached does not match any of the entries in that IPv6 ACL, the packet will be dropped by default. If you want to change this behavior to default (allow, for IPv6 ACLs), you can add an entry that matches all the packets and set the action as allow. To do this, use the following command:
ipv6 fhs ipv6-access-list no_match_src_def_allow 0:0:0:0:0:0:0:0/0 mode allow
IPv6 ACL entries with conflicting prefixes within an IPv6 ACLs are not allowed, and such configuration will fail with appropriate error message. Conflicting entries can be present in two or more different IPv6 ACLs.
The entries within an IPv6 ACL will be sorted in increasing order of IPv6 prefixes. If there are two entries with same prefix address within an ACL, then such entries will be ordered with increasing value of their prefix-lengths.
MAC ACL entries are ordered in the increasing order of MAC addresses within a MAC ACL. If none of the entries in the MAC ACL match the source MAC address of RA packet, then the packet will be dropped by default. If no MAC ACL is attached to an RA Guard policy, then the source MAC address of RA packets is not validated.
When matching for a prefix using IPv6 ACL entry, if you advertise a prefix with matching prefix but prefix-length lesser than configured prefix-length, then the packet has to be considered as no match and prefix matching process has to continue with remaining IPv6 ACL entries in that ACL.
The rationale behind this functionality is to avoid wrong configuration of access side devices. This functionality safeguards the devices in an access network if a wrongly configured IPv6 prefix is advertised or a malicious user is sending invalid (wrong) prefixes. For example, consider the following scenario:
Configure the prefix in ACL entry (without ge and le values): ipv6 fhs ipv6-access-list ipv6_acl_entry_1 2000:0123:4567:89ab::/64 mode allow
Advertise the prefix in RA packet: 2001:0123:4567:89ab::/48
This advertised prefix matches the configured IPv6 ACL entry and without this prefix-length check functionality, the packet is allowed to pass through. But, actually it is configuring all access devices in that network with wrong IPv6 configurations in different IPv6 network (2001:0123:4567::/48)
With prefix-length check functionality, this configuration is not allowed as advertised prefix length is not equal to configured prefix length. So, the wrong configuration of access devices is avoided.
Importance of “ge” and “le” parameters in an IPv6 ACL entry:
A user can optionally configure “ge” (greater than or equal to) and “le” (lesser than or equal to) parameters while configuring an IPv6 ACL entry. If the prefix advertised in a packet matches the configured prefix in an IPv6 ACL entry, and “ge” and “le” values are configured (not default) for that IPv6 ACL entry:
The packet will be allowed to go through only if the prefix-length in the packet is within the range of configured “ge” and “le” values.
If prefix lengths in the packet are not within the configured range of “ge” and “le” values (non-default values), then the packets would be considered as no match for that IPv6 ACL entry and search for matching IPv6 ACL entry continues within that IPv6 ACL.
If no ge and le values are configured, those values by default are set to configured prefix length in that IPv6 ACL entry.
ge and le values are allowed only if they are greater than configured prefix.
When both are configured (not default values), ge value should always be smaller than le value.
These configurations provide more control over the advertised prefixes in RA or DHCPv6 packets.
As “ge” and “le” values are valid only for advertised prefixes, they will not be applied to IPv6 addresses, which are not prefixes. For such addresses, prefix match is considered as match for that IPv6 ACL entry and the corresponding action of that ACL entry is applied on that packet. “ge” and “le” configurations are irrelevant for the following:
IPv6 source address in RA packet
IPv6 source address in packets from DHCPv6 server (like DHCPv6 advertise, DHCPv6 reply)
IPv6 address (temporary or non-temporary) advertised in packets from DHCPv6 server. For example, IPv6 addresses advertised in IANA option of DHCPv6 reply packets
Order of packet validations:
In RA or DHCPv6 packets received at the CP for FHS processing, the following order of processing is carried out:
Packet parsing
Checking for presence of IPv6 fragment header
Checking if packets are RA packets or DHCPv6 packets from server (Advertise, Reply, Reconfigure, Relay-Reply)
Non-Link-Local source IPv6 address (only for RA packets)
L4 length validations
Checksum validations
MAC ACL validations (if configured) (Only for RA packets)
IPv6 source address ACL validation (if configured)
IPv6 prefix ACL validations (if configured)
Managed config flag (RA)
ICMP hop limit (RA)
Router preference (RA)
Server preference (DHCPv6)
If any of these validations fail or if action associated with a match ACL entry indicates to DROP (or default drop if ACL is attached to corresponding policy but packet does not match any ACL entry in that ACL), then the packets are dropped and corresponding statistics are updated. If all these pass or actions related to all matched ACL entries are PERMIT, then the packet is allowed to go through.
Longest prefix match: If a packet matches multiple entries in an ACL, then the action associated with an entry with longest prefix match would be applied on the packet.
If a port is configured as untrusted (“host” as device role for RA Guard or “client” as device role for DHCPv6 Guard), all the FHS trusted traffic (RA packets for RA Guard or packets from DHCPv6 server for DHCPv6 Guard) are dropped in data path itself. Also for such drops, statistics are not incremented.
If a port is neither configured as trusted nor untrusted, then the FHS traffic (RA packets or DHCPv6 packets from DHCPv6 server) is switched as if FHS is not present.
Creation of FHS port policy mappings:
Until, and unless, any of the FHS parameters are configured on a port, port policy mappings are not created and thus with no port to policy mapping configured, the system does not display any entries while listing port policy mappings using the command show ipv6 fhs port-policy.
If a RA Guard or DHCPv6 Guard policy is attached to any of the ports, deletion of such policy is not allowed. In the contrary, to delete an RA Guard or DHCPv6 Guard policy, those policies need to be detached from all the ports in the switch. However, modification of an RA Guard or DHCPv6 Guard policy is allowed even if it is attached to ports.
If a MAC or IPv6 ACL is attached to an RA Guard or DHCPv6 Guard policy, you cannot delete the ACL itself. You can delete the entries from this policy even if it is attached to any policy. At least one entry needs to exist in a MAC or IPv6 ACL; you cannot delete the last entry in that ACL if that ACL is attached to any RA Guard or DHCPv6 Guard policy. You must detach that ACL from all the policies to delete that ACL. However, you can update the entries in that ACL even if it is attached to a policy.
If a port is configured as trusted (“Server” port for DHCPv6 Guard and “Router” port for RA Guard), then only one can attach a DHCPv6 Guard or RA Guard policy to that port. In the contrary, if any policy is attached to a port, the port role cannot be changed from trusted (“Server” port for DHCPv6 Guard and “Router” port for RA Guard) to other role (“Client” port for DHCPv6 Guard, “Host” port for RA Guard or “None” for both) until that policy is not detached from port.